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PROVIDING CLIENT ACCESS IBLE NETWORK- BASED STDRACF 

Background 

This invention relates to client-server environments and, more particularly, 
to diskless clients. 

As the average selling price of personal computers declines, computer 
5 manufacturers often look for ways to more efficiently serve the market. In a 
client-server network environment, many redundancies may exist which present 
opportunities for computer manufacturers. 

One possible redundancy is the use by several clients on a network of the 
same operating system and/or application programs. The vast majority of clients 
10 in a small business or educational environment have storage space that is 
identical and redundant. In particular, the storage space used for the operating 
system (such as Microsoft Windows) and the office productivity applications can 
take up to one gigabyte of space on a modern client. However, this is duplicated 
amongst the various clients. 
15 The idea of a diskless client or diskless workstation is not new. However, 

with the advent of a 100 Mbit Ethernet Network Connection, a diskless client may 
become more practical. The server for these diskless clients may be designed to 
offer each client an amount of disk storage dedicated for that client. The space 
on the server would be the equivalent of a "C" drive (or main hard disk drive) for 
20 the client 

One way to optimize server storage for diskless clients is to divide the 
client's files into two categories: shared and private. Those files that are normally 
shared by all clients are loaded into a different directory structure than the private 
files. Microsoft used this implementation to support diskless clients in Windows 
25 95. However, this implementation is problematic because most applications do 
not install and work property when operating system files are loaded into more 
than one directory structure. In part because of this, Microsoft chose to drop the 
diskless support after Windows 95. 

1 
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Other attempts to support diskless clients have been made. These 
methods tend to be highly complex and focus on using a higher-level file system 
protocol, such as the Network File System (NFS). However, particularly in low- 
end small business environments with very simple networks, such solutions may 
5 be too complex. 

Thus, there is a continuing need to provide a diskless client-server 
environment that works seamlessly with operating system and other software. 

Brief Description of the Drawings 
Figure 1 is a block diagram of a system according to one embodiment of 
10 the invention; 

Figure 2 is a flow diagram of the client request processor according to one 
embodiment of the invention; 

Figure 3 is a block diagram of the drive apportionment software according 
to one embodiment of the invention; 
15 Figure 4 is a detailed block diagram of the drive apportionment software 

according to one embodiment of the invention; 

Figure 5 is a flow diagram of operation of the drive apportionment software 
according to one embodiment of the invention; 

Figure 6 is a block diagram of the driver apportionment software using a 
20 cached according to one embodiment of the invention; 

Figure 7 is a flow diagram of the specialized BIOS of the client according to 
one embodiment of the invention; 

Figure 8 is a flow diagram showing operation of the client virtual boot 
record according to one embodiment of the invention; 
25 Figure 9 is a flow diagram showing operation of the disk drive controller 

proxy according to one embodiment of the invention; and 

Figure 10 is a block diagram of the system according to one embodiment 
of the invention. 
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Detailed Descri ption 
The following describes a system for providing network-based storage to 
clients on a network. For purposes of explanation, specific embodiments are set 
forth to provide a thorough understanding of the invention. However, it will be 
5 understood by one skilled in the art that the invention may be practiced without 
the particular details described herein. Further, although the embodiments are 
described in terms of hard disk drive storage media, the illustrated system may be 
applied to other non-volatile media, including, but not limited to compact disk 
read-only memories (CD ROMs), optical storage media, tape drives, flash 
10 memories, and option ROMs. Moreover, well-known elements, devices, process 
steps, and the like, are not set forth in detail in order to avoid obscuring the 
invention. 

In accordance with the several embodiments described herein, a server 
system on a network may support a plurality of diskless clients. Where possible, 

15 software on the server, and thus storage space, is shared between the diskless 
clients, providing an efficient network. Using special/zed firmware on the dient, 
the client is able to communicate with software on the server to redirect disk 
accesses. By providing a proxy for the disk drive controller on the client, 
operating system and other software operate as though the client has a local hard 

20 disk drive. 

In Figure 1, a system 100 includes a server 50 and a client 30, both 
connected to a network 40. The server 50 and the client 30 are both processor- 
based systems. In one embodiment, the server 50 and client 30 are connected to 
the network 40 using a fast Ethernet Local Area Network (LAN) protocol, which 

25 supports data transfer rates of 100 megabits per second. 

In one embodiment, the server 50 includes a plurality of software 60. For 
example, a client request processor 150 receives network packets indicating hard 
disk drive requests from the client 30. The client request processor 150 translates 
these requests such that other software 60 on the server 50 may process them. 

30 The client request processor 150 further translates results from operations 

performed on the server 50 such that they may be transmitted back to the client 

3 
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30. The client request processor 150, according to one embodiment, is described 
in connection with Figure 2, below. 

The server software 60 further includes drive apportionment software 200. 
The drive apportionment software 200 receives hard disk drive access requests 
5 from the client request processor 150. The drive apportionment software 200 
services the requests based upon a particular mapping of the hard disk drive on 
the server 50. The drive apportionment software 200, according to several 
embodiments, is described in more detail in connection with Figures 3 through 6, 
below. 

10 The server 50 further includes one or more client virtual boot records 250. 

The client virtual boot record or records 250, in one embodiment, may be 
downloaded to the client 30 following a request by the client 30 to boot. In some 
embodiments, the server 50 includes more than one client virtual boot record 
250, such that the various clients 30 on the network 40 may be flexibly 

15 configured. The client virtual boot record 250, according to one embodiment, is 
discussed in connection with Figure 8, below. 

In one embodiment, the server 50 further includes a client drive redirection 
driver 300. The client drive redirection driver 300, like the client virtual boot 
record 250, is downloaded to the client 30 during initialization. The drive 

20 redirection driver 300 receives requests to access a hard disk drive, which is not 
present on the client 30. Once loaded on the client 30, the drive redirection 
driver 300 transmit the requests over the network 40 to the server 50, such that 
the requests may be serviced on the hard disk drive of the server 50. The client 
drive redirection driver 300, according to one embodiment, is also described in 

25 connection with Figure 8, below. 

In addition to the software 60 on the server 50, the client or clients 30 
include both a specialized basic input/output system (BIOS) 350 and a disk drive 
controller proxy 400. In one embodiment, the specialized BIOS 350 is part of a 
memory 62, such as a read-only memory (ROM). The specialized BIOS 350 

30 assists the client 300 during power on such that the client 30 is connected to the 
network 40, receives the attention of the server 50, receives the virtual boot 
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record 250 from the server 50, and receives the drive redirection driver 300 from 
the server 50. Together, these operations permit the diskless client 30 to 
nevertheless service disk drive requests. The specialized BIOS 350, according to 
one embodiment, is discussed in connection with Figure 7, below. 

The disk driver controller proxy 400, in one embodiment, causes software 
running on the client 30 to believe that a disk drive controller is present on the 
client 30. Thus, software operating on the client 30 sends a disk drive request to 
the disk drive controller proxy 400, just as the software would send a request to a 
real disk drive controller. However, in some embodiments, the disk drive 
controller proxy 400 may operate differently than a disk drive controller. Instead, 
in one embodiment, the disk drive controller proxy 400 encapsulates the disk 
requests in packets such that they may be transmitted over the network 40, and 
ultimately serviced by the drive apportionment software 200 of the server 50. 

The disk drive controller proxy 400 may also receive packets from the 
network 40 and return the drive results to the requesting software. In one 
embodiment, the disk drive controller proxy 400 is hardware-based, embedded in 
a multi-purpose chip, such as a southbridge controller chip. In a second 
embodiment, the disk drive controller proxy 400 is firmware, stored in the ROM 
62 of the client 30. The disk drive controller proxy 400, according to one 
embodiment, is discussed in more detail in connection with Figure 9, below. 

The client request processor 150 may receive disk requests from the client 
30 encapsulated as network packets, as well as transmit responses to the disk 
operations back to the client 30. In Figure 2, the operation of the client request 
processor 150, according to one embodiment, begins by receiving by a packet 
over the network 40 on behalf of the client 30 (block 152). In one embodiment, 
the packet is an Ethernet packet. However, the packet may be transmitted using 
other protocols. 

From the packet, the client request processor 150 extracts a drive request 
from the encapsulated packet (block 154). The client request processor 150 then 
calls the drive apportionment software 200 (block 156). The drive apportionment 
software 200, in one embodiment, translates the drive request by the client 30 
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into a local storage request, that is, a request for the hard disk drive of the server 
50. 

After servicing the drive request, the client request processor 150 receives 
one or more results from the drive apportionment software 200 (block 158). 

5 Reversing the prior operations, the client request processor 150 encapsulates the 
drive results into packets (block 160), such that the packets may be transmitted 
over the network 40 (block 162). Thus, the operation of the client request 
processor 150, according to one embodiment, is complete. 

When the drive apportionment software 200 is called by the client request 

10 processor 150, the request may be serviced in a number of ways. For example, 
the server 50 may allocate a distinct portion of its storage space to each 
requesting client 30 on the network 40. On a typical network, each client 30 may 
boot the same operating system or may use the same application software as 
another client on the network 40. Thus, according to one embodiment, the 

15 system 100 allocates server 50 storage with this common usage model in mind. 

In Figure 3, according to one embodiment, the server 50 includes a non- 
volatile storage, such as a hard disk drive 80, including a common storage region 
82, as well as private storage regions 84 for each of the clients 30 on the network 
40. In a second embodiment, the non-volatile storage is an optical disk. 

20 In Figure 3, the network 40 includes client 30a, client 30b, and client 30c. 

Accordingly, the hard disk drive 80 includes client private storage 84a, client 
private storage 84b, and client private storage 84c. 

Further, the server 50 includes a memory 20, which stores an information 
database, such as a table, which keeps track of which client is using which portion 

25 of the hard disk drive 80. In one embodiment, the memory 20 stores a bitmap 
22, one for each client 30, to supply this information. For each client 30a, 30b, 
and 30c, the memory 20 includes distinct bitmaps: a client bitmap 22a, a client 
bitmap 22b, and a client bitmap 22c. These bitmaps 22 assist the drive 
apportionment software 200 to determine where on the hard disk drive 80 to 

30 service requests from the client 30. 
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Each bitmap 22 is comprised of a plurality of bits. In one embodiment, 
each bit represents a sector of disk storage available to each client 30, as 
between the common storage 82 and the private storage 84. Further, in one 
embodiment, the location of the bit 12 in the bitmap 22 represents the location of 
5 the sectors in the common storage 82. 

In Figure 4, the client bitmap 22a, according to one embodiment, is located 
in the memory 20 of the server 50, and includes a plurality of bits 12. In one 
embodiment, the number of bits 12 in the client bitmap 22a represents the 
number of sectors available to the client 30a, while the number of bits 12 set to a 
10 "l" represents the number of private sectors available to the client 30a. 

In Figure 4, the common storage 82 of the server 50 includes a plurality of 
sectors 86. Each bit 12 of the client bitmap 22a initially represents each sector 86 
of the common storage 82. However, in one embodiment, each time a bit 12 is 
set in the client bitmap 22a, a copy of the sector 86 is copied from the common 
15 storage 82 to the client private storage 84a as a private sector 88. 

In addition to identifying the number of sectors available to the client 30a, 
the bitmap 22a further may identify the location of the requested sector 86 on the 
hard disk drive 80. For example, in one embodiment, a w 0" in the bitmap 22a for 
bit 12 in the third position directs the drive apportionment software 200 to 
20 retrieve the third sector from the common storage 82 of the hard disk drive 80. 

By contrast, a "1" in the bitmap 22a for the ninth bit, bit 12a in Figure 4, 
indicates that the sector to retrieve was originally in the ninth position, sector 86a 
in Figure 4, of the common storage 82. However, the sector 86a has previously 
been copied to the client private storage 84a as private sector 88a. Because bit 
25 12a is the first non-zero occurrence in the client bitmap 22a, the first private 
sector 88a is retrieved from the client private storage 84a. Thus, the "1" in bit 
12a of the bitmap 22a directs the drive apportionment software 200 to retrieve 
the first private sector 88a from the private storage 84a on behalf of the 
requesting client 30a. Programmers of ordinary skill in the art recognize this as 
30 but one of several possible implementations of the client bitmap 22a. 

7 
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Thus, when all bits 12 in the bitmap 22a are set to "0", the drive 
apportionment software 200 retrieves all sector read requests from the common 
storage 82 of the hard disk drive 80. For some systems 100, the common storage 
area 82 may service the vast majority of accesses by the clients 30 on the 
5 network 40. For example, the loading of operating system and other application 
software typically involves only read operations. Accordingly, client 30a and client 
30c may share identical operating system software located in the common 
storage area 82 of the hard disk drive 80. 

Occasionally, the client 30 may perform write operations to its virtual 

10 storage. In one embodiment, when a sector write operation is requested by the 
client 30, the bit 12 corresponding to the requested sector 86 is set to a "1" (that 
is, if the bit 12 has not already been set). The relevant sector 86 is copied to the 
client private storage 84 as private sector 88, where the write operation may 
subsequently be performed. Once a write to a sector is made, all subsequent 

15 accesses to the sector are from the private storage 84 of the client 30. 

In Figure 4, four bits of the client 30 bitmap 22a are set to a A T', 12a, 12b, 
12c and 12d. Likewise, four sectors 86 of the common storage 82, 86a, 86b, 86c, 
and 86d, are copied to the client private storage 84a, as private sectors 88a, 88b, 
88c, and 88d. Thus, in one embodiment, the number of bits 12 which are set to 

20 X T' in the client bitmap 22 represents the number of private sectors 88 located in 
the client private storage 84. 

In Figure 5, the drive apportionment software 200, according to one 
embodiment, begins by receiving the hard disk drive 80 access request, such as 
from the client request processor 150, on behalf of the client 30 (block 202). In 

25 one embodiment, all read requests are initially serviced from the common storage 
82 of the hard disk drive 80. However, once a sector 86 is copied as a private 
sector 88 and the private sector 88 is written to, subsequent read requests of the 
sector 86 are directed to the private storage 84 of the client 30 and the 
associated private sector 88. Accordingly, the drive apportionment software 200 

30 determines whether a read or a write request is being made (diamond 204). 

8 
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If a read request is made, the drive apportionment software 200, running 
on the server 50, accesses the bitmap 22 of the client 30 from the memory 20 of 
the server 50. The bit 12 for the requested sector is tested (diamond 206). If 
the relevant bit 12 is set, a prior write operation to the private sector 88 may be 
presumed. If the bit 12 is not set, the requested sector 86 is retrieved from the 
common storage 82 of the server 50 (block 208). The requested sector 86 is then 
sent to the client request processor 150 (block 210). From there, according to 
one embodiment, the client request processor 150 sends the result across the 
network 40 to the client 30. 

If the relevant bit 12 of the client's bitmap 22 is set (diamond 206), then, 
although this is a read request, the private sector 88 is retrieved from the private 
storage 84 of the client 30 (block 212). The retrieved private sector 88 is then 
sent to the client request processor 150, where it is packetized and transmitted to 
the client 30 over the network 40. 

To process write requests (diamond 204), the drive apportionment 
software 200 reads the bitmap 22 of the client 30 to determine if the relevant bit 
12 is set (diamond 214). If so, the requested sector is already in the private 
storage 84 of the client 30 as private sector 88. Accordingly, the private sector 88 
is identified (block 220), then a write operation is performed on the private 
sector 88 in the client private storage 84 (block 222). 

If, however, the relevant bit 12 is not set in the client bitmap 22, the 
requested sector 86 is copied from the common storage 82 and stored as private 
sector 88 in the private storage 84 of the client 30 by the drive apportionment 
software 200 (block 216). The relevant bit 12 is then set in the client bitmap 22 
(block 218). This ensures that subsequent retrievals are to the private sector 88 
in the private storage 84 of the client 30, not from the sector 86 in the common 
storage 82. The requested private sector 88 is then written to in the private 
storage 84 of the hard disk drive 80 of the server 50 (block 222). Thus, the 
operation of the drive apportionment software 200, according to one 
embodiment, is complete. 



9 
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In some embodiments, much of the frequently used portions of the 
common storage 82 of the server 50 may be stored in a cache, such as a memory 
cache. In this way, read requests from the client 30 may be honored from in- 
memory cache, rather from the common storage 82 of the hard disk drive 80. In 
other embodiments, a processor cache is used to store commonly used portions 
of the common storage 82. The use of a cache may further speed operations 
such as booting or launching a productivity application by the client 30. 

In Figure 6, the server 50 includes the common storage 82, just as in 
Figure 4. The server 50 further includes a cache bitmap 24, which, like the client 
bitmaps 22, may be located in the memory 20 of the server 50. 

The memory 20 may further include a server cache 44. Like the client 
private storage 84 of Figure 4, the server cache may be used to transfer the 
sectors 86 from the common storage 82 as new sectors 92, such as for sectors 
which are frequently used. Unlike the client private storage 84, which is located 
on the hard disk drive 80, the server cache 44 is located in the memory 20. Thus, 
in one embodiment, accesses to the sectors 92 in the server cache 44 may be 
serviced at a substantially higher speed than those to the hard disk drive 80 of 
the server 50. In Figure 6, the frequently used sectors, 86e through 861, as 
indicated by the bits 12e through 121 in the cache bitmap 24, are accessible in the 
server cache 44 as sectors 92e through 921. 

In another embodiment, the client bitmaps 22 as well as the cache bitmap 
24 may identify blocks different from a sector in size for movement to the client 
private storage 84 or the server cache 44. A hard disk drive sector is typically 512 
bytes in length. However, modern file systems often deal with block sizes of 
seven sectors. The larger block size is used so that the file system runs more 
efficiently. So, for example, if a single sector is changed in the middle of a seven 
sector file system block, according to one embodiment, all seven sectors may be 
copied into the private storage 84 of the client 30 (or into the server cache 44). 
Accordingly, the bit 12 corresponding to the seven sector block may be set. 

In yet another embodiment, the client bitmaps 22 and the cache bitmap 24 

may be reset such that all bits 12 in the bitmap 22 are cleared to n 0". For a client 
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bitmap 22, this state may be identified as a default state of the client 30. The 
ability to reset the client 30 to a default state may be particularly useful in 
environments where the user of the client 30 changes. For example, in an 
educational setting, a student user may change on the client 30 every six months 
5 to a year. 

Looking back to Figure 1, the client request processor 150 and the drive 
apportionment software 200, in one embodiment, are not run until the client 30 
establishes a connection to the server 50. The specialized BIOS 350 of the client 
30 engages the server 50, such that the client 30 may receive the virtual boot 

10 record 250 as well as the one or more client drive redirection driver 300 from the 
server 50. Additionally, the disk drive controller proxy 400, "fakes out" any 
application software executed by the client 30, such that hard disk drive 
operations may be successfully performed on the client 30 even though the client 
30 itself has no hard disk drive. 

15 In short, according to one embodiment, the specialized BIOS 350 of the 

client 30, soon after the client 30 powers on, retrieves the virtual boot record 250 
and the client drive redirection driver 300 from the server 50. Once received, the 
virtual boot record 250 is executed on the client 30. During this time, any hard 
disk drive accesses, which are attempted by the virtual boot record 250, are 

20 redirected by the drive redirection driver 300 such that the disk drive controller 
proxy 400 of the client 30 is instead accessed. Then, the disk drive controller 
proxy 400 performs disk operations by accessing the hard disk drive 80 of the 
server 50. 

As illustrated in Figure 2, the packets comprising disk requests sent by the 
25 disk drive controller proxy 400 to the server 50 are handled by the client request 
processor 150. The disk drive controller proxy 400 operates from the perspective 
of the requesting boot record 250 (or any other application software), as though 
the drive operations are performed locally. Thus, the client 30 may support 
operating system and other software, some of which depend upon the presence 
30 of a hard disk drive, while, in fact, having no hard disk drive. 
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In Figure 7, the operation of the specialized BIOS 350, according to one 
embodiment, starts by connecting the client 30 to the network 40, for access to 
the server 50 (block 352). The specialized BIOS 350 next broadcasts a request 
for the server 50 (block 354). In one embodiment, the client 30 and the server 
5 50 operate as part of a pre-boot execution environment (PXE). The PXE 
Specification (Version 2.1, September 20, 1999) is available from Intel 
Corporation, Santa Clara, California. The client 30 initiates the PXE protocol by 
broadcasting a particular command that identifies the request as coming from a 
client that implements the PXE protocol. After several intermediate steps, the 

10 server 50 sends the client 30 a list of appropriate boot servers. The client 30 then 
discovers a boot server of the type selected and receives the name of an 
executable file on the chosen boot server. 

In one embodiment, the executable file received by the client 30 is the 
client virtual boot record 250 (block 356). Further, the specialized BIOS 350 

15 retrieves the client drive redirection driver 300, also from the server 50 (block 
358). Finally, the specialized BIOS 350 executes the virtual boot record 250 
(block 360). For example, the specialized BIOS 350 may perform a BIOS function 
INT19h, in order to execute the virtual boot record 250, which is loaded in a client 
memory. Thus, the operation of the specialized BIOS 350, according to one 

20 embodiment, is complete. 

Now that the client virtual boot record 250 is loaded in the client memory, 
the virtual boot record 250 may be executed. Note that when the boot record is 
located on the hard disk drive, it is typically loaded into memory and executed. 
Although retrieved from a remote hard disk drive, the virtual boot record 250 thus 

25 also operates in this manner. 

In Figure 8, the operation of the client virtual boot record 250, according to 
one embodiment, begins by issuing a command to load an operating system core 
(block 252). In the prior art, the operating system is typically loaded by issuing 
INT13h functions for retrieving the operating system from the hard disk drive. 

30 Here, instead, the drive redirection driver 300, received from the server 50 by the 

specialized BIOS 350, sends a request to the disk drive controller proxy 400 (block 
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254). In other embodiments, instead of using a driver to intercept the INT13h 
functions, the specialized BIOS 350 may itself redirect all INT13h functions to the 
disk drive controller proxy 400. 

To process the request, in one embodiment, the disk drive controller proxy 
5 400 retrieves the operating system from the server 50, using a protocol as 
described in connection with Figure 9, below (block 256). The operating system 
core is then loaded into the client memory (block 258). Once loaded, the 
operating system is executed (block 260). For all subsequent disk drive requests 
(e.g., run time requests), the drive redirection driver 300 may service the 
10 requests (block 262). Thus, according to one embodiment, the operation of the 
client virtual boot record 250 is complete. 

The disk drive controller proxy 400, invoked by the client virtual boot 
record 250 may look likes a normal disk drive controller to software running on 
the client 30, in one embodiment. This means that the disk drive controller proxy 
15 400 receives disk access requests. The operation of disk drive controller proxy 
400, according to one embodiment, is described in connection with Figure 9. 

First, the disk drive controller proxy 400 receives a request from operating 
system or other software loaded on the client 30, to access a hard disk drive 
(block 402). The disk drive controller proxy 400 encapsulates this disk request 
20 into packets suitable for transmission across the network 40 (block 404). 

In one embodiment, the client 30 employs a protocol for requesting sector 
accesses across the network 40 to the server 50. The protocol includes a private 
command and reply structure, including a command header section, a data 
content section, and an error handling section. Because the client request 
25 processor 150 is available for receiving the requests by the server 50, the 
commands from the disk drive controller proxy 400 may be simple, like "read 
sectors a, b, c, d" or "write sectors e, f, g, h". 

Next, according to one embodiment, the disk drive controller proxy 400 
sends the packet with the encapsulated disk request over the network 40 to the 
30 server 50 (block 406). The disk drive controller proxy 400 then waits for a 
response from the server 50. 

13 
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At some point, the disk drive controller proxy 400 receives the response 
packet, including the disk result, from the client request processor 150 of the 
server 50 (block 408). The disk drive controller proxy 400 next de-encapsulates 
the drive result from the packet as drive result data (block 410). The result data 
5 may then be stored in the memory of the client 30 (block 412), such that the data 
may be retrieved by the requesting application. Thus, the operation of the disk 
drive controller proxy 400, according to one embodiment, is complete. 

Referring to Figure 10, the server 50 includes a processor 10, and the 
memory 20, including the cache 44, as described in connection with Figure 6, 
10 above. The processor 10 may comprise a microcontroller, an X86 microprocessor, 
an Advanced RISC Machine (ARM) microprocessor, or a Pentium-based 
microprocessor, to name a few. The memory 20 may comprise various types of 
random access memories, such as dynamic random access memories (DRAMs), 
synchronous DRAMs (SDRAMs), static RAMs (SRAMs), single in-line memory 
15 modules (SIMMs), or double in-line memory modules (DIMMs), to name a few. 

Both the processor 10 and the memory 20 are connected via a system bus 
14. In one embodiment, a bridge chip 16 is also coupled to the system bus 14, 
such as for including a second bus 18, such as a peripheral component 
interconnect (PCI) bus 18. The PCI specification is available from the PCI Special 
20 Interest Group, Portland, Oregon 97214. 

In one embodiment, the bridge chip 16 further supports the hard disk drive 
80, including the software 60 as shown in connection with Figure 1. The PCI bus 
18 may also support a network interface card (NIC) 42, for connecting the server 
50 to the network 40. 

25 The client 30 is also a processor-based system, including a processor 58, a 

memory 64, and the ROM 62, each coupled to a system bus 56. Like the 
processor 10 on the server 50, the processor 58 may include any of a variety of 
processors. Also like the server 50, the memory 64 may be any of a variety of 
random-access memories. 
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As in Figure 1, the ROM 62 includes the specialized BIOS 350. The ROM 
62 may be a programmable ROM (PROM), an erasable programmable ROM 
(EPROM), and electrically erasable PROM, and so on. 

Uke the server 50, the client 30 includes a bridge chip 52 coupled between 
5 the system bus 56 and a PCI bus 48. The PCI bus 48 may also support a NIC 
card 46, for connection to the network 40. In one embodiment, the disk drive 
controller proxy 400, as in Figure 1, may be part of the multi-function bridge chip 
52. In other embodiments, the disk drive controller proxy 400 may be a separate 
and distinct component, coupled to the system bus 56 or the PCI bus 48. The 
10 embodiment of Figure 10 thus represents one of many possible implementations 
of the illustrated system 100. 

Thus, in some embodiments, a system for supporting diskless clients 
exploits the redundant needs of the clients on a network. Where possible, the 
client may share accesses to the hard disk drive of the server. The clients 
15 nevertheless may maintain private storage on the server, where needed. In some 
embodiments, the client includes a specialized BIOS for establishing connection to 
the server and downloading an operating system. In some embodiments, the 
client further includes a drive controller proxy for re-routing drive requests to the 
server. The server likewise includes specialized software, for servicing the remote 
20 requests, for allocating drive space to the various clients, and for downloading 
operating system and driver software to the client, in some embodiments. 

While the present invention has been described with respect to a limited 
number of embodiments, those skilled in the art will appreciate numerous 
modifications and variations therefrom. It is intended that the appended claims 
25 cover all such modifications and variations as fall within the true spirit and scope 
of this present invention. 
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What is claimed is: 

1. A method, comprising: 

generating on a client a request to access a non-volatile storage; 
receiving the request by a nonvolatile storage proxy on the client; 

5 and 

accessing the non-volatile storage on a server by the non-volatile 
storage proxy. 

2. The method of claim 1, accessing the non-volatile storage on a 
server by the non-volatile storage proxy further comprising: 

10 encapsulating the request into a packet suitable for transmission 

over a network; and 

sending the packet to a server connected to the network. 

3. The method of claim 2, further comprising: 
receiving the packet by the server; 

15 de-encapsulating the request from the packet; and 

producing a result based upon the request. 

4. The method of claim 3, producing a result based upon the request 
further comprising: 

identifying a block of the non-volatile storage on the server; 
20 performing an operation on the block based upon the request; and 

receiving in the non-volatile storage proxy a result from the server. 

5. The method of claim 4, identifying a block of the non-volatile 
storage on the server further comprising: 

accessing a table associated with the client in a volatile memory of 
25 the server; and 

16 



WO 01/97016 



PCT/US01/17263 



finding an entry in the table associated with the block. 

6. The method of claim 4, receiving in the non-volatile storage proxy a 
result from the server further comprising: 

receiving a second packet encapsulating the result produced by the 

5 server; and 

de-encapsulating the result from the second packet. 

7. The method of claim 5, further comprising: 
reviewing the entry associated with the block; 

identifying the block as having previously been written to by the 

10 client; and 

retrieving the block from a first portion of the non-volatile storage 
on the server wherein the first portion is associated with the client. 

The method of claim 5, further comprising: 
reviewing the entry associated with the block; 
identifying the block as not having previously been written to by the 

retrieving the block from a common portion of the non-volatile 
the server. 

9. The method of claim 5, further comprising: 
storing the result in a volatile memory of the client. 

10. A system comprising: 
a server, comprising a non-volatile storage; 
a network coupled to the server; and 

a client coupled to the network, the client including a non-volatile 

storage proxy that receives a storage access request and forwards the 

storage access request to the server over the network. 

17 
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11. The system of claim 10, wherein the non-volatile storage proxy 
forwards the storage access request to the server over the network by: 

encapsulating the storage access request into a packet; and 
sending the packet over the network to the server. 

12. The system of claim 11, wherein the server further: 
receives a packet from the client on the network; 
extracts the storage access request from the packet; and 
accesses the non-volatile storage in response to the storage access 

request. 



10 13 - The system of claim 12, wherein the server further: 

produces a result associated with accessing the non-volatile storage; 
encapsulates the result in a second packet; and 
sends the second packet over the network to the client 

14. The system of claim 13, wherein the non-volatile storage proxy 
15 further: 

receives the second packet from the client over the network; 
de-encapsulates the result from the second packet; and 
sends the result to a memory on the client. 

15. The system of claim 10, wherein the client includes no non-volatile 
20 storage. 



16. The system of claim 10, wherein the client further comprises a 
software program to: 

broadcast a server request on the network; 
retrieve a virtual boot record from the server; and 
execute the virtual boot record. 

18 
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17. A system, comprising: 
a processor; 

a network interface for connecting the system to a network; and 
a non-volatile storage proxy coupled to the processor, wherein the 
5 non-volatile storage proxy: 

receives a non-volatile storage access request; 

encapsulates the non-volatile storage access request into a 

packet; and 

sends the packet out over the network interface to a server. 



18. The system of claim 17, wherein the non-volatile storage proxy 
further: 

receives a second packet from the server; and 
de-encapsulates a result from the second packet. 



19. The system of claim 18, wherein the result is produced by the server 
15 following an access to a non-volatile storage located on the server in response to 
the request received by the server from the system. 



20. The system of claim 17, further comprising: 

a non-volatile memory storing a software program executed during 
power-on of the system, wherein the program: 

broadcasts a request for the server on the network; 
retrieves a virtual boot record from the server; 
stores the virtual boot record in the memory; and 
executes the virtual boot record. 



21. The system of claim 20, wherein the program further: 

retrieves a redirection driver from the server; 

stores the redirection driver in the memory; and 
19 
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loads the redirection driver. 

22. The system of claim 21, wherein the drive redirection driver sends 
the request to access the non-volatile storage to the non-volatile storage proxy. 

23. An article comprising a medium storing a software program that, 
upon execution, causes a processor-based system to: 

generate on the processor-based system a request to access a non- 
volatile storage; 

receive the request by a non-volatile storage proxy on the 
processor-based system; and 

access the non-volatile storage on a server by the non-volatile 
storage proxy. 

24. The article of claim 23, further storing software that, upon 
execution, causes a processor-based system to access the non-volatile storage on 
a server by the non-volatile storage proxy by: 

encapsulating the request into a packet suitable for transmission 
over a network; and 

sending the packet to a server connected to the network. 

25. The article of claim 24, further storing software that, upon 
execution, causes a processor-based system to: 

receive the packet by the server; 
de-encapsulate the request from the packet; and 
produce a result based upon the request. 

26. The article of claim 25, further storing software that, upon 
execution, causes a processor-based system to produce a result based upon the 
request by: 

identifying a block of the non-volatile storage on the server; 

20 
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performing an operation on the block based upon the request; and 
receiving in the non-volatile storage proxy a result from the server. 

27. The article of claim 26, further storing software that, upon 
execution, causes a processor-based system to identify a block of the non-volatile 

5 storage on the server by: 

accessing a table associated with the processor-based system in a 
volatile memory of the server; and 

finding an entry in the table associated with the block. 

28. The article of claim 27, further storing software that, upon 
10 execution, causes a processor-based system to: 

review the entry associated with the block; 

identify the block as having previously been written to by the 
processor-based system; and 

retrieve the block from a first portion of the non-volatile storage on 
15 the server wherein the first portion is associated with the processor-based 
system. 

29. The article of claim 27, further storing software that, upon 
execution, causes a processor-based system to: 

review the entry associated with the block; 
identify the block as not having previously been written to by the 
processor-based system; and 

retrieve the block from a common portion of the non-volatile storage 
on the server. 

30. The article of claim 26, further storing software that, upon 
execution, causes a processor-based system to receive in the non-volatile storage 
proxy a result from the server by: 
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receiving a second packet encapsulating the result produced by the 

server; and 

de-encapsulating the result from the second packet. 
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